hopefully the real fix for garmin_xt tool issues. (#781)
Fix LGTM detected "Comparison between i of type uint8_t and Count of
wider type int."
This latest find by LGTM is one in a long series of issue detections by
various tools. However, close analysis reveals the previous solutions
to these deteced issues didn't find or fix the real root issues:
commit
233f3c8b0bf69397403b6c1f29af8e10a65a8928, 10/22/2013, Pad
internal buffer to appease -fsanitize=address. While the fix appeased
the sanitizer, it didn't fix the root problem. The root problem was
a bug in the original translation of format_garmin_xt_decrypt_trk_blk
when converting to zero-based array indexing.
commit
dcf0dd85a71c6fa5fc3dac72520c2070ba051108, 7/8/2015, A bunch of
busy work to satisfy hyperactive warnings in newer GCC builds. Again,
the fix didn't fix the root problem. The root problem was a bug in the
original translation of format_garmin_xt_proc_strk. This bug resulted
in a mismatch between our test output and that of the original project.
In our output the timestamp of the last two points in a track was
identical.
This fix results in our output matching the reference file of the original
project (with allowances for precision).